Enterprise level applications share resources through the use of a cross system lock scheme. This scheme has been used in applications by SAP AG of Waldorf, Germany. For example, the cross system lock scheme was used in the SAP enterprise resource planning (ERP) 6.0 product. FIG. 1 is a diagram demonstrating the cross system lock scheme. The cross system lock scheme operates on a model of a ‘network of equals,’ where each system or application that gains control of a resource has the same rights to modify and utilize the resource. The cross system lock scheme requires that each participant be fully compatible with its protocol requirements including support for synchronous remote function calls (RFCs), and similar tight application coupling requirements involving double commit logic and character-based token structures that includes the application business key. These requirements restrict the use of the cross system lock scheme to fully compatible systems and exclude legacy systems from interoperability. Also, the cross system lock scheme has only a single document level for locking a resource. That is, the cross system lock scheme locks the document at the header level, such that an entire document is locked and only the holder of the key can modify any part of the document.
The illustration of FIG. 1 demonstrates the cross system lock scheme. In the illustrated example, the system 101 is seeking to gain control of a resource. The system 101 sends a request for control of the resource to the last known holder of the token the represents the authority to control and change the resource. The last known holder of the token for system 101 is system 103. However, the information of system 101 is out of date. System 103 no longer is in possession of the token. The token had previously been passed to system 105. System 103 then forwards the request of system 101 to system 105. The movement of the token in this manner and the imperfect information available to the systems in the cross system lock scheme can result in a long chain of message forwarding to get a request to the current holder of the token. This increases network communication and diminishes the resources of the intermediate systems that must pass on messages to the current token holder.
Once the request reaches the current holder of the token, the holder responds to the request depending on its current use of the resource. If the token holder is still utilizing the resource, then the request is denied and the token remains with the current token holding system 105. If the holder is no longer using the resource, then the request is accepted and the token is passed to the requesting service 101. However, if a system holding the token continues to use the resource (through normal operation or error of that system), then other systems are unable to gain access to that resource.